1. Field of the Invention
This disclosure involves a method for the ability to verify the validity of a physically consistent database copy in a state of Quiesce prior to, or during, the recovery process so as to prevent subsequent wasting of time if inaccurate data has been allowed to accumulate.
2. Description of Related Art
The process of making a database unavailable for update activity is counter-productive to the goal of maintaining the database availability for 24 hours a day, 7 days a week and 365 days a year. Currently, with the present types of database systems, a database system must be taken off-line (QUIESCE) to create a physically consistent snapshot copy for the purpose of the offloading of database processing in a mirrored disk environment.
The present invention relates to the method of replicating an external physically consistent database copy from a primary on-line database system. An on-line database system maintains a logically consistent database by (i) reading data from disk storage into a system memory storage, then (ii) making changes to data by updating system memory storage, and then (iii) writing the changed data to disk storage at periodic intervals. When there are no active users of a database system, all the modified or changed data is written from the system memory storage to the disk storage, and then the system can be taken off-line with the database in a physically consistent state. However, with the advent of physically mirrored disk storage, the database system process of off-loading of a physically consistent copy is enabled and the performance can be improved, whereby the primary system remains available for normal operations and the secondary system is available for backup operations.
As previously stated, the process of making the database unavailable for update activity is counter-productive to the goal of maintaining 24 hour, 7 day a week, 365 days a year of database availability. Thus, if a physically consistent database copy could be created from a primary on-line database system, the database availability will still be maintained while the system performance is improved when a physically mirrored snapshot is used to off-load the processing.
An example of such a remote mirroring system is illustrated in U.S. Pat. No. 6,044,444 to Yuval Ofek of the EMC Corporation. This involves a data processing system which automatically and asynchronously, with respect to a first host system, generates and maintains a backup or “mirrored” copy of a primary storage device at a different location physically remote from the primary storage device. This is done without any intervention from the primary host which might seriously degrade the performance of the data transfer link between the primary host computer and its primary storage device.
This U.S. Pat. No. 6,044,444, provides a method of mirroring physical storage in order to create a duplicate copy, described as a “physically mirrored snapshot”. However, this U.S. Patent to Ofek of EMC Corporation does not teach or show any method that provides full integrity checking of physical consistency in the duplicate copy, nor does this patent teach or show any method for verification of the duplicate copy.
A DMUTILITY program currently in the present invention provides the ability to recover data from a database or database copy that is marked as being in a state of QUIESCE. However, no one has ever provided the ability to verify the validity of the database copy prior to, or during the recovery process. This has now been accomplished.
A newly provided option to VERIFY a secondary database copy, therefore, will enable verification of a database copy marked as being in a state of QUIESCE. This option will be available with a DMUTILITY DBDIRECTORY statement, or with a DMUTILITY RECOVER statement. This verification will perform integrity checks for every Block of every structure or for all structures in the specified <dbdirectory list> of a DBDIRECTORY statement or the <recover spec> of a RECOVER statement. The integrity checks performed will include CHECKSUM and ADDRESSCHECK for structures that have CHECKSUM or ADDRESSCHECK database options set.
When the VERIFY option is requested with the DBDIRECTORY statement, any errors will be reported and handled in a manner consistent with existing reports and handling behavior when performing a DUMP with an indication: “**WARNING: THIS ROW LOCKED OUT (NOT ACCESSIBLE).” When all rows of all structures have been completed, a completion message is reported. If no errors were encountered, then the message “VERIFY OPTION IS COMPLETE, NO ROWS LOCKED OUT” will be given. If errors were encountered, the message “VERIFY OPTION IS COMPLETE, # ROWS LOCKED OUT” will be given, where the “#” will be replaced by the number of rows encountered with the CHECKSUM or ADDRESSCHECK integrity errors. If the VERIFY option is used with the RECOVER command and integrity errors were found, then the following message is given and the RECOVERY activity will not start; “AX OK TO CONTINUE, AX QUIT TO STOP”. RECOVER activity will either continue or stop based on the given response to the message.